home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 657 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  5.2 KB
  1. From: Mark.Baker@mettav.royle.org (Mark Baker)
  2. Date: 29 Jun 94  21:57:16
  3. Message-Id: <UUCP.773001152@mettav>
  4. Subject: Re: Dialog Box Proposal Part 1 
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Craig:
  9.  > But some applications DO allow select/cut/paste from inside an edittable
  10.  > text field using the mouse (eg. the Myriad MiNT only desktop).
  11.  > I think that the mouse cursor should be changed to reflect any object
  12.  > it can effect (as it does under Xwindows/Motif).
  13.  
  14. Motif does it for you, trying to do it yourself would need some fairly
  15. complicated code, particularly since the aes only lets you watch two
  16. rectangles.
  17.  
  18.  > The clipboard CPX's I've tried all crash on a falcon......
  19.  
  20. The SDS one does; the Atari one seems to work on my falcon, although it doesn't
  21. have the features of the SDS one.
  22.  
  23. Ofir:
  24.  >> How about having always the 2 possibilities? e.g. active-drawing with
  25.  >> the left button, and ghost-drag with the right button (or shift-left
  26.  >> button).
  27.  >
  28.  > Due to the way GEM works, I think we should leave the right mouse button
  29.  > alone since it lets you click on background windows.
  30.  
  31. This is the convention the desktop uses; it isn't done automatically and it
  32. isn't easier to program than any other use of the right button. OTOH, the fact
  33. that the desktop and a few other programs use this convention mean we should
  34. stick to it.
  35.  
  36. Christian:
  37.  > Since we want to set standards for other things as well, we should better
  38.  > put the big-cursor paradigm in the standard now, since it's well
  39.  > established on the ATARI and in all other major GUI's. Those who still
  40.  > want to implement the other sort of blocks (damn, isn't there a good name
  41.  > for it? ) can make up their own shortcuts.
  42.  
  43. The big-cursor paradigm is easier for using with the mouse, but not so good for
  44. keyboard users IMO. The standard should allow for apps to use either method and
  45. have suitable shortcuts for both. I don't mean all programs should support
  46. both, although the turbo-C++ editor for windows does very nicely.
  47.  
  48.  > Tempus), but everyone has a different set of shortcuts for the block, and
  49.  > none of them understands ^X/^C/^V.
  50.  
  51. I use LED all the time which does use ^X/^C/^V.
  52.  
  53.  > I feel misunderstood. More precisely, apps that only support undo and
  54.  > redo can use Undo alternatively for both. Those with multi level-Undo can
  55.  > use Undo for step-wise undo and Control or Shift - Undo for Step-wise
  56.  > redo.
  57.  
  58. You're right, I did misunderstand you - what you say here makes sense and I
  59. think the original proposal was a bit confusing.
  60.  
  61. [Hide]
  62.  >> What's wrong with just iconifying?
  63.  > Doesn't work for MagiC (yet), and the menu bar will stay there.
  64.  
  65. The menu bar's hardly obtrusive, since it will be replaced by another apps as
  66. soon as you try and use it.
  67.  
  68.  > Apple's Human Interface Guidelines suggest "Revert to Saved"
  69.  
  70. Yes, that's fairly unambiguous. Actually Apple's guidelines are worth a read,
  71. although they are too comprehensive IMO as there is no way you could remember
  72. all the recommendations.
  73.  
  74. Rainer
  75.  >> Conclusion: including a list of internationally available key
  76.  >> combinations in the shortcut standard is necessary IMO.
  77.  >
  78.  > Not to forget the key combinations of alternative (PC-like) keyboards.
  79.  
  80. Which combinations aren't available on PC-like keyboards?
  81.  
  82.  > Deselect sounds better to me. With 'hide' I think of something like
  83.  > hiding behind a tree. (I hope you understand what I'm trying to say)
  84.  
  85. Yes, you kind of expect the text to disappear from the screen. Deselect is
  86. better, deselect all in object based apps and deselect block in text based
  87. ones.
  88.  
  89. Timothy:
  90.  >> I might have a go. Mine would use standard resource files, with the
  91.  >> extended types used for special objects. I would use the same extended
  92.  >> types as interface despite not having it :)
  93.  >>
  94.  > If you use standard resource files, how are you going to put in all the
  95.  > extentions?  Of course, you'll have to have a totally custom written
  96.  > dialog drawing routine.
  97.  
  98. Just use lots of progdefs. Use the extended types, and when the resource file
  99. is loaded you call a routine which checks this byte then makes the objects
  100. progdefs, saves the old ob_spec value and fills in the ob_spec fields depending
  101. what type it is. I'll only have to supply custom routines for the objects I
  102. replace, which will be providing CUA-style toggles first, with other new
  103. features such as speedo fonts in editable fields coming later. I'll try to make
  104. it so it can be used by a programmer with as little extra effort as possible.
  105.  
  106. Ken:
  107.  > Warwick, I think my method is MUCH easier to do.  You don't have to
  108.  > check for the rectangles, all you have to do is check to see if the
  109.  > mouse enters an editable object or not...
  110.  
  111. But this means responding to timer events and it slows the system down.
  112. Warwick's method has less effect on the speed.
  113.  
  114.  > Ofir, I thought the method I had written down was clear cut and easy to
  115.  > understand.  LEFT Shift and Delete: Clear to the LEFT of the cursor.
  116.  > RIGHT shift and Delete: Clear to the RIGHT of the cursor.  BOTH shifts
  117.  > and Delete: Same as ESC.  What's so hard about that?  :)
  118.  
  119. Nothing hard about it, it's just totally different from anything else. Follow
  120. the existing standard. Also, IMO there is only one situation in which it is
  121. acceptable for the shift keys to be different, and that's turning the player in
  122. games.
  123.  
  124.  
  125.  
  126.